Sentry に Rails のエラー情報を送る時に気になったことを調べたログ

2024/4/18

Sentry に Rails のエラー情報を送る設定方法は公式の方で示されている

code:ruby

begin

rescue StandardError => e

Sentry.capture_exception(e)

end

(2024/4/19追記)

code:ruby

rescue_from StandardError, with: :handle_internal_server_error

private

def handle_internal_server_error(error)

Sentry.capture_exception(error)

# 以下省略(ログ出力したりレスポンスに入れるメッセージ用意するとかなやつ)

end

設定する中で、例外処理周りの記述についての知識が浅いなーと感じてくる

rescue_fromでExceptionやStandardErrorを指定すると、Railsでの正しい例外ハンドリングが阻害されて深刻な副作用が生じる可能性があります。よほどの理由がない限り、このような指定はおすすめできません。

StandardError に直接 rescue_from やるの非推奨なのか

Rubyで独自例外を定義するときはExceptionではなく、StandardError を継承するしきたりとなっています。

下記がビルトインのExceptionのサブクラスたちです。rescueのデフォルトがStandardError、raiseのデフォルトがRuntimeErrorとなっています。

上の例で MyExceptionは補足されない。なぜなら、rescue は第1引数で指定した例外クラスの下の階層にある例外だけを補足するけど、引数を省略すると StandardErrorクラスを指定したものとみなすからだ。MyExceptionはException直下の子クラスなので、rescue されない。

Exceptionを直接継承した自前定義の例外クラスを複数作って、それらを補足しようと思うと、いちばん上にあるExceptionごと補足するしかない。そうすると今度は、すべての例外を補足することになってしまう。例えば、exitを呼ぶと発生するSystemExitも補足されてしまう。これは恐らく望ましい動作ではない。

上記の記事2つを読んでなるほどね〜となってくる

Exception でカスタム例外クラスを継承した場合、引数省略した書き方だと StandardErrorクラスの下の階層にある例外だけを補足するので rescue されない

rescueのデフォルト引数がStandardErrorクラスであるため

Exceptionごと補足する書き方(rescue の引数にExceptionを指定)になると、すべての例外を補足することになり補足してほしくない例外も補足されてしまうのでそれは望ましい動作ではない

カスタム例外の話を追いたくなって以下の記事も読んだ

小話